Minutes, IBIS Quality Committee 27 October 2009 11-12 AM EST (8-9 AM PST) ROLL CALL Adam Tambone * Anders Ekholm, Ericsson Barry Katz, SiSoft Benny Lazer Benjamin P Silva Bob Cox, Micron * Bob Ross, Teraspeed Consulting Group Brian Arsenault David Banas, Xilinx * Eckhard Lenski, Nokia Siemens Networks Eric Brock Guan Tao, Huawei Technologies Gregory R Edlund Hazem Hegazy Huang Chunxing, Huawei Technologies John Figueroa John Angulo, Mentor Graphics Katja Koller, Nokia Siemens Networks Kevin Fisher Kim Helliwell, LSI Logic * Lance Wang, IOMethodology Lynne Green, Green Streak Programs * Mike LaBonte, Cisco Systems Mike Mayer, SiSoft * Moshiul Haque, Micron Technology Muniswarareddy Vorugu, ARM Ltd Pavani Jella, TI Peter LaFlamme Randy Wolff, Micron Technology Radovan Vuletic, Qimonda Robert Haller, Enterasys Roy Leventhal, Leventhal Design & Communications Sherif Hammad, Mentor Graphics Todd Westerhoff, SiSoft Tom Dagostino, Teraspeed Consulting Group Kazuyoshi Shoji, Hitachi Sadahiro Nonoyama Lijun, Huawei Everyone in attendance marked by * NOTE: "AR" = Action Required. -----------------------MINUTES --------------------------- Mike LaBonte conducted the meeting. Call for opens and patent disclosures: - No one declared a patent. - Mike noted that a vote of acceptance for the IQ 2.0 spec is planned for this Friday at the IBIS Open Forum teleconference. AR Review: - Lance try to find IBIS files with [Diff Pin] Tdelay out of order - Talked to TI, but have not received a file yet - All review the IQ spec for possible new IBISCHK checks - Discussed in this meeting New items: Discussion of possible IBISCHK enhancements based on IQ checks: Mike: IQ 5.5.3 would be good candidate for IBISCHK "5.5.3. {LEVEL 2} [Ramp] dV consistent with I-V table calculations" - Mike: It would have to use combined I/V tables - But IBISCHK does not consider [Add Submodel] - Bob: [Ramp] must be created with no [Submodel] in effect - Mike: Why exclude a Driving mode Submodel? - Bob: [Submodel] is just a parasitic to the base model - Mike: It should use whatever Submodels are in effect at time 0 in driving mode - But if [Submodel] has it's own [Ramp] then maybe the turnon/turnoff characteristics are separate - Lance: So the [Ramp] has to be separated - This is not a problem because these models barely exist now - Anders: We make them separate entities - [Ramp] is to create K factors - Mike: The same would apply to [Driver Schedule] as well - We agreed that each [Model] [Submodel] and scheduled model has it's own [Ramp], so they must be checked uncombined Lance: Would it be an ERROR or WARNING? - Mike: Maybe WARNING, since the IBIS spec does not require consistency - Lance: And [Ramp] may not even be used by simulators - Bob: It is between CAUTION and WARNING, and will be decided in Open Forum - We do not need 2 levels based on percentage for this one - This probably should be a CAUTION - Eckhard: How about a WARNING if waveforms are present, ERROR if not? - Bob: The dV data are not really used, it should not be an ERROR - dV is redundant with waveforms - Anders: Redundant model data are useful for consistency checks - Bob: Tools are "on their own" if they use [Ramp] dV for simulation - We should have had dt only in the original IBIS specification - Mike: Did Quad have both dt and dV? - Anders: They had only dt Mike: The test model could have no waveforms and 2 point I/V tables - Anders: If dV is not important why check this? - Mike: Because dt is derived from the dV thresholds and may also be wrong - Mike: What should the error threshold be? - Anders: IQ 5.5.3 says 5% of dV - Bob: It could be 5% of 100% swing - Anders: IQ says 5% of the 60% swing - Mike: We could discuss the percentage at Open Forum this Friday - If someone suggests a different number the IQ spec should change Bob: We will have to consider if we want to generate a new WARNING - Mike: Not many models will fail this, in our experience - Anders: Some simulators use [Ramp] for initial timestep determination - People don't know how to handle this - Mike: Then I agree with Bob that it should be a CAUTION - Bob: It should be sent to the ibis-bug email list AR: Mike write IBISCHK bug for 5.5.3 Anders: Does the IQ spec suggest using the IBISCHK -caution option? - Mike: Not inclined to make a last minute IQ spec change for this - We would want to look over the existing CAUTIONs first - Bob: CAUTION gives more information - It is usually for something that does not have a serious impact - It helps to see if you missed something Anders: We should keep a wishlist - Mike: Should the wishlist be in the minutes like the ATM or on our web page? - Anders: It should be on the web page AR: Mike add wishlist to IQ web page Mike: What next? - Mike: We could begin work on correlation and the Accuracy Handbook next week - Moshiul: We should discuss updating the IQ checklist spreadsheet - We agreed to this Mike will send an Open Forum email when we are about to discuss correlation Meeting ended at 11:59 PM Eastern Time.